The invention relates generally to database backup systems and procedures and more particularly to database backup systems and procedures that are implemented using a mirror copy of the primary database.
Database systems, like many other things, are vulnerable to failures, sometimes disastrous enough to corrupt the data within the database so that it is no longer usable. To protect against such failures, database managers typically backup their data periodically. The backup operation is usually done during a window of time when loads on the database system are the lowest, e.g. late at night. If there is a window during which no work is being done, the backup can be done offline. However, if no such period exists, the backup must be done online (i.e., while other transactions are being processed). In either event, once the backup has been performed, if a failure or mistake corrupts or destroys the data on the primary online database, it can be restored from a copy that was generated during the backup operation.
Databases continue to grow in size while backup windows are shrinking. Today storage systems can handle terra bytes of data. Incremental backups for this amount of data are not usually available. Two conventional ways for doing backup are: (1) to move data through a network connected to the backup server; or (2) to run special backup software on the same machine that is running the database application. Due to bandwidth limitations of most networks, going through the network can be slow. Whereas, running backup software tends to put a considerable load on the data storage system and the host processor, e.g. the mainframe computer. While they are loaded down with handling the backup, their capability for handling business transactions goes way down. And if there is a very high volume of business transactions, the system can easily become unacceptably unresponsive. Alternatively, the backup rate goes down and the backup process will take an unacceptably long period of time. In other words, current backup solutions leave something to be desired because data is either moved through a slow network or excessive loads are placed on the database host/storage subsystem.
Two parallel avenues have been pursued for solutions. One solution path has been a database server managed backup. Data, mostly in the form of incremental changes, is passed by the database backup server to third party backup management software. The backup management software stores the data to tertiary storage. The tertiary storage can be directly attached to the database node or it can be services provided over the network. An advantage of this approach is that support for incremental backups should result in less data that needs to be backed up. Thus, loads on the resources will be reduced. Another advantage is that data integrity verification occurs at the backup times. A disadvantage is that incremental backups can reduce but they do not eliminate resource loads. Complete backups still place excessive loads on the system.
A second solution path has been to do physical backups at the datafile level. In this case, backups are performed outside of the database server. And all interactions with the database management system are done via management interfaces. The backup management software stores data to tertiary storage with minimal or no loads on the database server/storage subsystem. That is, the paths to the tertiary storage typically bypass or minimize use of the network. An advantage of this approach is that it should result in high speed backups since loads on the database host/storage subsystem are minimal. But a disadvantage is that incremental backups are very difficult and likely not to be feasible. In addition, data integrity verification is usually not feasible at backup time.